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Dialogue  Management  is  an  emerging  field  which  emphasizes  a  spe¬ 
cialization  in  the  development  of  quality  human-computer  interfaces. 
It  encompasses  the  design,  implementation,  simulation,  execution, 
maintenance,  and  metering  of  dialogues  in  an  integrated  environment. 
Several  key  concepts  in  dialogue  management  have  been  identified  in 
response  to  the  need  for  improved  human- computer  interfaces.  These 
concepts  are  surveyed  here,  and  their  importance  to  dialogue  design 
and  management  is  discussed.  Dialogue  independence  and  internal  and 
external  dialogue  are  manifest  in  the  separation  of  the  dialogue  com¬ 
ponents  of  a  software  system  from  the  computational  components.  In  a 
new  system  design  role,  a  dialogue  author  is  responsible  for  creating 
the  dialogue  which  constitutes  the  human- computer  interface  of  an 
application  system.  A  holistic  methodological  approach  to  system 
development  places  emphasis  on  the  development  of  both  dialogue  and 
computational  components  of  an  application  system.  Systems  are  now 
being  built  which  incorporate  many  of  these  important  concepts  in  the 
management  of  dialogues  for  human-computer  systems.  Several  of  these 
systems  are  mentioned  as  examples  of  concepts  application,  and  one 
such  system  is  described  in  some  detail. 
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faces;  structured  programming;  top-down  programming;  user  interfaces; 
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User/Machine  Systems- -human  factors 
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Dialogue  Management: 


New  Concepts  in  Human-Computer  Interface  Development 

H.  Rex  Hartson 
Deborah  H.  Johnson 

Department  of  Computer  Science 
Virginia  Polytechnic  Institute  and  State  University 
Blacksburg,  VA.  24061 


"As  we  grow  more  familiar  with  the  intelligent  environment, 
and  learn  to  converse  with  it  from  the  time  we  leave  the 
cradle,  we  will  begin  to  use  computers  with  a  grace  and 
naturalness  that  is  hard  for  us  to  imagine  today.  And  they 
will  help  all  of  us--not  just  a  few  ' super- technocrats ' --to 
think  more  deeply  about  ourselves  and  the  world."  [ TOFF80 ) 


INTRODUCTION 

As  the  "Gestalt  of  the  computer"  [R0SE74]  becomes  more  pervasive 
in  our  society,  the  key  to  the  real  effectiveness  of  computers  in 
that  society  will  be  usability  by  people  other  than  computer  profes¬ 
sionals.  As  the  quotation  above  suggests,  the  effectiveness  of  this 
amazing  machine  is  limited  not  by  its  power  to  compute,  but  rather  by 
its  power  to  communicate.  The  roots  of  poor  human-computer  communi¬ 
cation  are  deeply  embedded  in  the  methods  currently  used  to  design 
large  interactive  systems.  Despite  recent  advances  in  methodological 
approaches  to  software  design,  these  improvements  have  not  yet 


addressed  the  important  parallel  issue  of  human-computer  dialogue 
development.  Many  researchers  have  proposed  viable  solutions  to  spe¬ 
cific  issues  in  this  area.  Yet  many  of  these  issues  represent  only  a 
small  portion  of  a  sizable  problem.  These  existing  issues  and  their 
solutions  have  generally  been  addressed  without  a  framework  for  a 
larger  strategy  for  dialogue  management.  It  is  the  purpose  of  this 
paper  to  identify  and  assemble  some  concepts  of  this  new  field,  to 
provide  the  beginnings  of  such  a  framework.  In  addition,  many  of  the 
issues  of  human-computer  interface  development  bear  relationships  to 
existing  areas  of  computer  science,  particularly  structured  program¬ 
ming,  software  engineering,  formal  languages,  and  data  abstraction. 
The  key  to  a  solution  lies  in  reassessing  the  entire  software  devel¬ 
opment  process.  This  paper  reports  on  recent  progress  in  the  evolu¬ 
tion  of  some  new  concepts,  new  roles,  and  new  tools  that  are  just 
emerging  from  this  reassessment.  Although  artificial  intelligence 
considerations  such  as  natural  language  and  knowledge-based  user 
models  are  very  much  a  part  of  the  broader  subject  of  human- computer 
dialogue,  they  are  excluded  from  the  scope  of  this  paper. 

Traditional  Systems  and  Their  Problems 

Traditional  software  systems  design  is  often  aimed  mainly  at 
development  of  efficient  and  functionally  correct  computational  code. 
Since  getting  the  system  debugged  and  operational  depends  mainly  on 
the  correctness  of  the  computational  component  of  the  software,  the 
effectiveness  of  the  dialogue  component  gets  little  consideration. 


An  application  programmer  rarely  has  either  the  skills  and  knowledge 
or  the  time  and  patience  to  create  effective,  human-factored  dia¬ 
logues,  but  is  typically  much  more  intent  upon  the  development  of 
algorithms  and  other  computational  considerations.  The  software 
designer  may  even  find  it  distracting,  in  the  middle  of  a  lengthy, 
logically  complex  piece  of  software,  to  have  to  write  dialogue  to 
communicate  with  the  user.  But  this  dialogue  comprises  the  all-im¬ 
portant  interface  with  which  human  users  must  interact.  If  that 
interface  is  not  created  so  that  most  humans  can  perform  the  task 
they  set  out  to  do,  it  matters  little  whether  the  computational  part 
of  the  code  works  properly  or  not.  Also  in  traditional  systems, 
since  both  computational  code  and  dialogue  generally  are  written  by 
an  application  programmer  and  are  therefore  tightly  interspersed,  the 
dialogue  is  actually  a  part  of  the  computational  software.  This 
often  makes  it  difficult  to  change  easily  either  the  dialogue  or  the 
computational  part.  The  dialogue  to  be  altered  must  first  be  found 
in  a  maze  of  functional  code  and  then  the  desired  changes  made.  When 
the  dialogue  is  embedded  in  the  computational  code,  changes  to  dia¬ 
logue  may  propagate  all  the  problems  associated  with  changes  to  the 
computational  program. 

Related  Work 

Much  research  has  been  done  in  an  attempt  to  improve  human-com¬ 
puter  communication.  The  groundwork  for  development  of  effective 
human-computer  interfaces  was  laid  during  the  last  decade.  This  work 


was  largely  a  collection  of  subjective  "principles"  for  interface 
design  [HANS71 ,  MART73,  KENN74,  ROUS75,  CHER76,  MILL77,  SMIT80).  Not 
surprisingly,  among  the  leaders  of  this  early  work  were  some  who  spe¬ 
cialized  in  graphics  [FOLE74,  NEWM79 ] .  Very  few  of  these  principles 
are  experimentally  validated,  however.  Of  the  approximately  500 
guidelines  compiled  from  this  and  other  relevant  literature  [WILL81], 
only  a  small  portion  had  any  empirical  basis.  Also,  many  c  tradic- 
tions  and  inconsistencies  were  found  among  the  "principle  in  the 


literature . 


Only  recently  has  empirical  evaluation  of  the  humai  -  ...puter 


interface  and  its  design  been  stressed  [SHNE80]  and  communication 


1.  DIALOGUE  MANAGEMENT:  AN  EMERGING  FIELD 


The  discipline  of  dealing  with  the  creation,  modification,  simu¬ 
lation,  execution,  testing,  and  metering  of  dialogues  in  an  inte¬ 
grated  manner  has  been  called  "dialogue  management"  IEHRI81).  The 
term  is  indicative  of  an  emerging  field  that  embodies  a  specializa¬ 
tion  in  the  development  of  quality  human-computer  interfaces. 

1.1.  FUNCTIONS  OF  HUMAN- COMPUTER  DIALOGUE 

Dialogue,  as  it  relates  to  a  human- computer  interface  in  the 
traditional  sense,  refers  to  the  interaction  between  a  human  and  the 
computer  system  being  used.  It  is  the  means  by  which  the  human  gives 
commands  or  queries  to  the  computer  and  by  which  the  computer  res¬ 
ponds  to  or  queries  the  user.  This  discourse  ir  thus  the  exchange  of 
words,  phrases,  parameterized  commands,  and  other  symbols  and 
actions,  i.e.,  the  conversation,  between  a  human  and  a  computer. 

This  human-corrputer  dialogue  is  composed  of  two  separate  parts: 
the  computer's  part  and  the  human's  part.  The  computer's  part  of  the 
dialogue,  of  course,  is  actually  written  by  humans  and,  therefore, 
could  be  considered  to  be  human- to-human  dialogue,  offset  in  time. 
The  human's  part  is  any  input  a  user  may  gi.e  to  the  system  at  execu¬ 
tion  time.  It  is  confusing  and  indeed  erroneous  to  think  of  a 
human-computer  dialogue  as  being  only  what  is  actually  displayed  to 
the  user  by  the  system,  (i.e.,  what  is  coded  into  the  software 
itself).  Instead,  both  the  human  side  and  the  computer  side  of  the 
dialogue  must  be  considered  in  the  design  of  a  specific  discourse. 
Multi-party  grammars  | SHNE82b ]  have  evolved  as  a  method  to  explicitly 
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specify  both  the  human  input  and  the  computer  response  for  a  human- 
computer  dialogue. 

Human-computer  dialogue  has  two  distinct  functions:  1)  to 

request  information  (either  from  the  user  or  from  the  computer)  and 
2)  to  transmit  information  (either  to  the  user  or  to  the  computer). 
Most  programs,  in  order  to  execute,  must  have  input  (e.g.,  "name", 
"SSN",  "edit",  numerical  data)  from  the  user.  This  input  is  typi¬ 
cally  obtained  through  prompts  or  queries  which  ask  the  user  for  spe¬ 
cific  information.  These  requests  are  coded  at  appropriate  points 

into  the  computational  software  itself.  When  the  system  needs  to 

$ 

transmit  information  to  the  user  (e.g.,  "searching  database", 
"unmatched  left  parenthesis"),  this  is  also  done  through  some  predet¬ 
ermined  dialogue  built  into  the  software.  A  combination  of  transmit¬ 
ting  and  requesting  information  is  manifest  in  a  menu,  which  displays 
possible  options  and  then  asks  the  user  to  choose  one.  The  content 
and  format,  as  well  as  the  logical  sequencing,  of  dialogue  is 
extremely  important  in  determining  how  well  the  user  can  understand 
and  manipulate  the  system. 

1.2.  NEW  CONCEPTS  IN  DIALOGUE  MANAGEMENT 

As  research  has  progressed,  some  concepts  have  emerged  upon 
which  a  new  approach  to  human-computer  interface  design  can  be  based. 
It  is  the  purpose  of  this  paper  to  identify  and  highlight  those  con¬ 
cepts,  primary  among  which  are  a  software  design  and  implementation 
concept  called  dialogue  independence,  a  separate  design  role  called  a 
dialogue  author,  and  a  holistic  methodological  approach  to  interac- 
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tive  system  design.  The  remainder  of  this  paper  will  present  these 
new  concepts  in  the  context  of  various  current  research  efforts  and 
will  conclude  by  relating  them  to  a  particular  system  for  dialogue 
management  (DMS)  which  is  being  developed  and  implemented. 

2.  DIALOGUE  INDEPENDENCE 

2.1.  WHAT  IS  DIALOGUE  INDEPENDENCE? 

The  design  of  a  large  software  system  represents  a  significant 
commitment  of  resources  in  terms  of  both  people  and  money.  In  tradi¬ 
tional  software  systems,  dialogue  and  computational  code  are  inextri¬ 
cably  interwoven  together  so  that  a  commitment  to  one  is  a  commitment 
to  both.  In  the  design  of  a  system,  major  emphasis  is  placed  on  the 
development  of  the  computational  component.  The  result  is  that  dia¬ 
logue  becomes  less  and  less  changeable  as  the  design  progresses.  It 
is  often  later  in  the  design  process  when  the  dialogue  issues  are 
understood  more  completely  and  human  factors  experiments  can  be  per¬ 
formed,  if  necessary,  to  design  a  better  human-computer  dialogue. 
Unfortunately,  by  this  time  in  the  development  process,  the  design  is 
already  committed  to  an  ineffective  dialogue. 

Therefore,  an  important  criterion  for  the  design  of  human-compu¬ 
ter  interfaces  is  fast,  easy  modification  of  the  dialogue  of  a  spe¬ 
cific  system.  Because  research  in  this  area  properly  involves  empir¬ 
ical  studies  of  human-computer  interaction  and  dialogue  design,  this 
flexibility  is  even  more  important.  The  dialogue  may  need  revision 


both  for  the  experiments  themselves,  as  well  as  to  incorporate  the 
results  of  experimentation  back  into  the  dialogues. 

Several  years  ago,  database  researchers  and  designers  encoun¬ 
tered  a  similar  problem  in  the  need  for  easy  modification  of  data 
without  the  necessity  to  change  the  corresponding  programs.  Data 
independence  has  emerged  as  a  solution  to  this  key  issue  in  database 
development.  Data  independence  is  a  concept  that  directs  database 
design  in  such  a  way  that  changes  to  data  are  independent  from,  and 
therefore  do  not  usually  necessitate  changes  to,  the  application  pro¬ 
gram  which  manipulates  that  data.  A  formal  data  definition  allows 
the  decoupling  of  data  instances  from  the  programs.  An  analogous 
concept,  called  dialogue  independence  [ROAC82a],  allows  changes  to 
dialogue  that  do  not  mandate  modifications  to  computational  code. 

Typically,  a  structured  software  system  is  divided  into  modules, 
which  apply  a  single  action  or  function  to  a  single  object.  In  trad¬ 
itional  software  systems,  dialogue  and  computation  are  usually  mixed 
together,  often  in  the  same  module.  This  means  that  the  need  for  a 
change  to  the  dialogue  may  require  searching  through  countless  pages 
of  source  code  to  find  the  lines  that  need  to  be  changed.  This  pro¬ 
gram  structure  can  also  make  the  process  of  following  a  program's 
computational  logic  very  difficult,  when  READs  and  WRITES  to  request 
and  transmit  and  check  and  validate  and  re-request  information 
between  the  user  and  the  system  are  constantly  interrupting  the 
natural  flow  of  the  computational  code.  Dialogue  independence  helps 
to  alleviate  some  of  these  difficulties  by  allowing  easy  alteration 
of  dialogues  without  the  associated  problems  of  changing  computa- 


Dialogue  independence  is  achieved  by  both  logical  and  physical 
separation  of  dialogue  from  computational  software,  which  requires 
that  dialogue  and  computational  functions  do  not  appear  in  the  same 
module.  This  means  that  the  executable  code  of  an  application  system 
is  composed  of  dialogue  modules  as  well  as  computational  modules. 
Intuitively,  a  dialogue  module  is  used  to  carry  out  "one  interac¬ 
tion's  worth"  of  dialogue,  and  such  modular  packaging  is  similar  to 
that  commonly  used  for  computational  software.  The  "dialogue  compo¬ 
nent"  of  a  software  system  is  a  collection  of  all  dialogue  modules 
and  the  "computational  component"  is  a  collection  of  all  computa¬ 
tional  modules.  These  components  are  bound  together  at  some  time 
before  or  during  execution.  As  a  result,  dialogue  and  computational 
components  can  be  modified  to  a  great  extent  without  each  affecting 
the  other. 

Since  there  can  be  more  than  one  dialogue  component  for  a  single 
computational  component,  an  application  system  can  have  two  or  more 
very  different  user  interfaces.  Foley  [ F0LE81 )  and  Feldman  | FELD82 ) 
have  captured  this  concept  in  their  Abstract  Interaction  Handler, 
which  contains  knowledge  of  interaction  styles,  allowing  their 
style- independent  applications  to  be  used  with  more  than  one  kind  of 
interface.  Feldman  and  Rogers  [ FELD82 ]  advocate  the  separation  of 
the  user  front-end  from  the  system  semantics,  even  to  the  point  of 
being  able  to  customize  user  interfaces  for  individual  users 
[FELD81].  The  dialogue  independence  of  their  system  semantics  allows 
experimental  evaluation  of  various  interfaces  while  holding  the 
underlying  computational  system  constant.  However,  use  of  libraries 


of  "interaction  handling  modules"  may  have  limited  advantages  in 
light  of  the  goal  of  tailoring  an  interface  for  different  user 
classes  as  well  as  different  users.  It  would  seem  that  each  applica¬ 
tion  system  must  still  be  analyzed,  and  its  specific  dialogue  needs 
addressed.  Even  though  a  given  interaction  module  has  "known  human- 
factors  attributes",  those  attributes  were  tested  for  a  specific  kind 
of  interaction  in  a  specific  system  and  may  not  be  applicable  in  a 
different  situation. 

This  ability  to  keep  flexible  the  design  of  a  user  interface 
relates  to  another  important  concept  in  dialogue  management,  that  it 
is  often  as  important  to  make  a  system  human- factorable  as  it  is  to 
make  it  human-factored.  Dialogue  independence  is  a  prerequisite  for 
human-factorability,  especially  when  it  is  not  always  clear  during 
the  early  stages  of  system  design  what  is  needed  to  make  a  system 
human- factored. 

2.2.  SEPARATION,  BUT  NOT  DIALOGUE  INDEPENDENCE 


The  separation  of  the  user  interface  from  the  rest  of  the  appli¬ 
cation  software  is  not  an  entirely  recent  idea.  The  literature  con¬ 
tains  several  descriptions  of  systems  for  which  such  a  separation  was 
attempted  after  the  system  was  implemented.  That  is,  generalized 
user  interfaces  were  developed  to  be  used  as  add-on  front-ends  to 
existing  application  systems.  [BASS81]  and  [WRIG78]  each  report  on 
front-ends  which  were  implemented  to  provide  easy-to-understand  dia¬ 
logue  with  which  to  pass  system  commands  and  parameters.  In 
[BASS81],  the  interface  for  a  statistical  analysis  package  operated 


in  a  system  command  and  a  job  control  command  environment,  and 
applied  to  both  batch  and  on-line  jobs.  Essentially  one  interface 


was  adapted  to  this  diversity  of  use  in  one  application.  In 
[WRIG78],  the  interface  was  custom-coded  to  a  single,  specific  medi¬ 
cal  application.  Both  of  these  groups  began  with  an  existing  appli¬ 
cation  system  which  did  not  have  an  easily  usable  interface,  and 
attempted  to  revise  the  human-computer  dialogue  to  meet  their  needs. 
Thus,  the  systems  achieved  separation  of  dialogue  and  computation, 
but  not  true  dialogue  independence,  since  the  approach  was  not  gener- 
alizable  and  extensible  to  other  systems,  or  even  to  other  interfaces 
for  the  same  systems.  These  approaches,  also,  did  not  consider  the 
computational  component  in  the  overall  design. 

The  work  on  a  demographic  database  system  reported  in  [ EVAN82 ] 
is  somewhat  similar.  Here  an  adaptable  user  interface  provided  more 
than  one  dialogue  to  an  existing  software  system  as  needed  to  suit 
the  varying  requirements  of  different  user  communities.  Separation 
of  the  interface  from  the  rest  of  the  system  made  this  possible. 

Hayes,  Ball,  and  Reddy  [HAYE81)  refer  to  the  independence  of  the 
user  interface  from  the  application  program  as  "tool  independence". 
Their  concept  of  a  quality  interface  is  one  that  supports  graceful 
interaction  in  the  sense  that  human- to-human  communication  is  grace¬ 
ful  and  robust.  Graceful  interaction  thus  goes  well  beyond  the  trad¬ 
itional  "principles"  of  human-computer  interaction  of  the  variety 
mentioned  in  section  1  of  this  paper  and  into  the  realm  of  natural 
language  understanding  ( HAYE79 i .  Because  of  the  enormous  difficul¬ 
ties  of  producing  such  an  interface,  they  propose  to  amortize  this 


effort  by  building  an  application-independent  system  that  will  serve 
as  the  user  interface  for  many  application  systems.  Application 
independence  is  achieved  by  having  all  knowledge  of  the  application 
in  a  separate  declarative  database,  rather  than  in  the  interface 
itself.  Such  an  interface  system  will  also  provide  a  consistent  user 
view  across  all  the  applications  for  which  it  is  used.  Intuitively, 
however,  use  of  the  "same"  interface  would  seem  to  preclude  the  pos¬ 
sibility  of  tailoring  the  user  interface  over  a  broad  range  of  appli¬ 
cation  programs  and  user  types  (e.g.,  naive  secretary  to  experienced 
engineer) .  It  would  seem  better  to  generate  different  interface  ins¬ 
tances  for  each  application.  Consistency,  in  addition  to  the  flexi¬ 
bility  of  a  customized  interface,  could  be  achieved  by  using  a  com¬ 
prehensive  development  methodology  and  a  common  set  of  tools  (in  the 
context  of  system-building,  not  in  the  Hayes,  Ball,  and  Reddy  con¬ 
text)  to  generate  these  interfaces. 

2.3.  DEVICE  INDEPENDENCE 

No  discussion  of  dialogue  independence  would  be  complete  without 
reference  to  the  related  and  more  well-known  concept  of  device  inde¬ 
pendence.  Device  independence  is  used  to  shield  the  application  pro¬ 
grammer  from  the  special  detailed  characteristics  of  the  devices 
through  which  the  application  system  communicates  with  its  users  and 
from  the  technical  differences  in  those  details  from  device  to  device 
IHILL81,  EHRI82].  Figure  1  shows  the  relationship  of  dialogue  inde¬ 
pendence  to  device  independence. 
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Figure  1.  Dialogue  Independence  and  Device  Independence 
2.4.  INTERNAL  AND  EXTERNAL  DIALOGUE 

When  an  application  system  is  separated  into  a  computational 
component  and  a  dialogue  component,  the  computational  part  contains 
no  mechanism  for  direct  communication  with  the  user;  i.e.,  it  con¬ 
tains  no  dialogue  in  the  traditional  sense,  since  all  dialogue  which 
interfaces  with  the  user  is  now  in  the  dialogue  component.  Under 
this  kind  of  separation,  an  application  system  will  consist,  at  its 
lowest  level,  of  distinct  dialogue  modules  and  computational  modules. 
The  dialogue  modules  may  contain  the  text  and  graphics  which  are  dis¬ 
played  to  the  user,  and  where  necessary,  contain  the  mechanisms  for 
receiving  and  processing  user  input  and  transmitting  it  to  the  compu¬ 
tational  part.  The  computational  modules  perform  the  functional  pro- 


cessing.  When  the  computational  component  needs  information  or  data 
from  the  user  to  continue  processing,  it  makes  a  call  to  the  appro¬ 
priate  dialogue  module.  The  dialogue  module  then  interacts  with  the 
user  to  obtain  the  necessary  input,  possibly  parses  it,  checks  the 
input  for  type  and  range,  and  returns  it  to  the  computational  module. 
Similarly,  when  the  computational  component  needs  to  transmit  infor¬ 
mation  to  the  user,  it  again  calls  the  appropriate  dialogue  module 
which  displays  the  information  to  the  user.  Since  the  collection  of 
computational  modules  thus  interfaces  with  the  user  only  through  the 
dialogue  modules,  the  computational  modules  would  appear  to  be  dia- 
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Figure  2.  Internal  and  External  Dialogues 

logue-free.  Computational  modules,  however,  do  engage  in  a  less 
obvious  form  of  dialogue,  which  is  an  "internal  dialogue"  with  the 
dialogue  modules  so  that  the  program  can  obtain  data  in  order  to  exe¬ 
cute.  (See  Figure  2.) 

The  interaction  between  the  user  and  the  dialogue  modules  is 
"external  dialogue",  the  interaction  which  is  typically  thought  of  as 
making  up  the  human-computer  interface.  External  dialogue  is  highly 
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varying  in  form  and  content.  The  part  expressed  to  the  user  by  the 
computer  is  limited  only  by  the  imagination  of  the  person  who  creates 
the  content  of  the  dialogue  modules  and,  hopefully,  principles  of 
good  human -computer  communication.  Similarly,  the  possible  inputs 
that  a  human  can  give  to  the  computer  are  virtually  infinite.  Cer¬ 
tainly  only  a  very  small  subset  of  these  possible  inputs  will  be 
valid,  but  the  potential  for  the  others  still  exists  and  must  be 
dealt  with  by  appropriate  messages. 

Internal  dialogue,  on  the  other  hand,  has  no  direct  connection 
to  the  user  of  the  system,  but  serves  as  a  link  between  the  dialogue 
modules  and  the  computational  component  of  a  system.  It  can  there¬ 
fore  be  formally  specified,  is  much  less  variable  in  its  form,  and 
does  not  have  to  be  human-understandable.  The  formal  specification 
of  internal  dialogue  is  the  real  key  to  dialogue  independence. 
Either  dialogue  or  computation  can  be  changed  without  affecting  the 
other,  as  long  as  each  remains  consistent  with  the  definition  of 
their  common  interface. 

These  two  kinds  of  dialogues  can  be  seen  to  occur  in  most  of  the 
approaches  which  use  separation  of  dialogue.  For  example,  in 
[ BORU82 ] ,  external  dialogue  occurs  at  the  user  interface  and  internal 
dialogue  happens  at  the  application  interface. 
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3.  DIALOGUE  AUTHOR 


3.1.  TRADITIONAL  ROLES  IN  SYSTEM  DESIGN 


For  many  years,  the  two  main  roles  involved  in  software  develop¬ 
ment  were  those  of  the  application  programmer  and  the  end-user  of  the 
system.  These  two  types,  however,  frequently  had  severe  communica¬ 
tion  problems.  The  programmer,  impatient  to  begin  coding,  often  had 
difficulty  understanding  the  user's  requirements.  Similarly,  the 
user  was  not  often  able  to  articulate  the  needs  of  the  system  and  was 
baffled  by  the  strange  "computerese"  in  which  the  programmer  tried  to 
explain  what  was  happening.  The  lack  of  communication  between  these 
two  often  resulted  in  systems  that  were  not  what  the  user  wanted  or 
needed,  but  what  the  programmer  decided  to  provide.  Gradually,  the 
need  was  recognized  for  someone  who  could  understand  both  the  techni¬ 
cal  (programmer)  and  non-technical  (user)  sides  of  the  system.  This 
role  is  that  of  a  systems  analyst. 

The  user,  however,  might  possibly  be  knowledgeable  in  only  the 
one  or  two  facets  of  the  system  used  most.  So  the  role  of  applica¬ 
tion  expert  evolved,  one  who  knew  all  aspects  of  system  requirements 
and  uses  thoroughly.  The  systems  analyst  serves  as  a  liaison  between 
application  expert  (and/or  users)  and  application  programmer,  aiding 
and  guiding  both  in  defining  and  communicating  system  requirements. 
But  neither  the  systems  analyst  nor  the  application  expert  was  con¬ 
cerned  primarily  and  explicitly  with  the  human-computer  interface. 
In  the  last  few  years,  human- factors  specialists  have  become  an 
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increasingly  important  part  of  computer  system  design  and  development 
teams  for  just  this  reason.  They  attempt  to  emphasize  the  incorpora¬ 
tion  of  human-factors  considerations  into  computer  systems,  and 
especially  into  the  dialogues,  so  that  the  user  has  an  effective 
interface  with  which  to  interact.  But  a  human-factors  expert  fre¬ 
quently  knows  little  about  implementation  of  dialogues.  Thus,  a  new 
role,  that  of  a  dialogue  author,  has  been  created  to  design  and 
implement  dialogues.  The  term  "dialogue  author"  was  first  presented 
in  [EHRI81]  and  rapidly  began  appearing  in  subsequent  literature. 

3.2.  FUNCTIONS  OF  THE  DIALOGUE  AUTHOR 

For  the  programmer,  communication  with  the  machine  is  very 
different  from  communication  with  a  human.  Thus,  an  application  pro¬ 
grammer,  whose  skill  has  been  developed  to  deal  with  computers,  is 
not  a  likely  candidate  to  produce  human-oriented  dialogue.  The  know¬ 
ledge  and  skills  required  to  create  effective  human-computer  interac¬ 
tions  are  quite  different  from  those  needed  to  write  computational 
software.  The  programmer  may  even  find  it  annoying  in  the  midst  of  a 
logically  complicated  section  of  code  to  have  to  "change  modes"  and 
write  dialogue  to  interact  with  the  user,  for  example,  to  solicit  an 
input  value.  It  is  even  more  distracting  from  the  computational  pro¬ 
gramming  task  to  have  to  check  the  value  received  from  the  user  for 
all  possible  errors  and  to  respond,  in  case  of  an  error,  with  consis¬ 
tently  worded  error  messages  and  prompts  for  correct  inputs.  Thus, 
these  interactions  are  frequently  written  as  quickly  as  possible, 
with  little  thought  given  to  their  form  or  content. 
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Additionally,  the  independence  of  dialogue  modules  from  computa¬ 
tional  modules  indicates  the  need  for  separate  roles  to  create  the 
two  components.  Thus,  the  role  of  a  dialogue  author  has  been  devel¬ 
oped.  The  dialogue  author  is  a  skilled  communication  specialist 


whose  ultimate  goal  is  to  create  and  implement  human-factored  dia¬ 
logues.  Because  application  programmers  will  no  longer  write  dia¬ 
logues,  the  dialogue  author  "will  have  sole  responsibility  for  creat¬ 
ing  an  interface  for  a  user.  The  dialogue  author  is  not  specifically 
a  programmer,  but  rather  is  a  specially  trained,  human-f actors-o- 
riented  professional  concerned  with  the  high  level  sequencing  of  com¬ 
puter-user  interaction,  as  well  as  the  form,  style,  and  content  of 
specific  dialogues"  [HART82]. 

In  addition  to  creating  human-factored  dialogues,  the  dialogue 
author  is  interested  in  evaluation  and  revision  of  dialogue  modules. 
Particularly  since  much  human  factors  research  encompasses  empirical 
testing  of  dialogues,  the  dialogue  author  is  interested  in  metering 
the  dialogues  and  in  incorporating  newly  discovered  principles  and 
guidelines  into  the  dialogues.  The  separation  of  dialogue  and  compu¬ 
tational  components  of  the  software  through  dialogue  independence 
allows  these  modifications  to  be  made  quickly. 


3.3.  TOOLS 


The  people  working  in  this  relatively  new  field  of  human-compu¬ 
ter  interaction  seem  to  be  very  tool-oriented.  Many  recent  articles 
in  the  literature  describe  tools  for  the  development  and  testing  of 
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human-computer  dialogue.  This  is  undoubtedly  the  "first  wave"  of  an 
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even  more  comprehensive  phenomenon,  related  to  the  fact  that  people 
who  are  designing  human-factored  interfaces  for  others  are  not  con¬ 
tent  to  have  poor  quality  interfaces  for  their  own  work.  The  dia¬ 
logue  author,  even  though  creating  a  component  of  a  software  system, 
does  not  program  the  dialogue  modules  in  the  way  that  an  application 
programmer  programs  the  computational  modules.  Instead,  the  dialogue 
author  requires  a  special  environment  designed  specifically  to  aid  in 
the  implementation  of  dialogue  modules. 

Among  the  tools  being  developed  to  design,  implement,  simulate, 
test,  and  maintain  dialogue  are  special  functions  to  format  text, 
generate  graphics,  produce  keypad  outlines  and  touch-panel  configura¬ 
tions,  and  voice  I/O  managers.  Generic  tools  that  serve  the  dialogue 
author  across  the  spectrum  of  these  specific  tools  include  dialogue 
editors,  dialogue  simulators,  and  dialogue  databases.  Rule-based 
"expert"  dialogue  designers  [ROAC82b,  FISC82)  guide  the  author  in 
applying  human-factors  considerations,  graphic  design  principles,  and 
guidelines  for  effective  communication. 

The  tools  generally  fall  into  two  categories:  those  that  are 
used  as  dialogue  design  aids  to  help  the  author  design  the  content 
and  sequencing  of  dialogue  modules  (e.g.,  a  design  "expert"  and  a 
dialogue  simulator)  and  those  that  are  used  as  dialogue  implementa¬ 
tion  aids  to  help  the  author  produce  dialogue  modules  with  a  particu¬ 
lar  content  (e.g.,  text  and  graphics  formatters  and  dialogue  edi¬ 
tors).  There  are  also  tools  to  facilitate  experimentation  with  human 
factors  in  interactive  displays  IF0LE81,  FELD81],  including  languages 
and  metrics  for  interface  specif ication  and  ergonomic  evaluation 


[ BLES81 ] ,  and  tools  to  implement  early  and  inexpensive  experimental 
user  interfaces  [ FELD82 ] . 

The  TAXIS  | MYL080 ]  system  for  designing  and  programming  interac¬ 
tive  information  systems  includes  high-level  programming  language 
facilities  integrated  with  database  management  and  integrity  checking 
mechanisms.  TAXIS  provides  tools  for  the  specification  of  the  seman¬ 
tic  (computational)  component  of  interactive  information  systems. 
Barron  [ BARR80 ]  has  extended  TAXIS  tools  to  a  pragmatic  component  for 
the  description  of  processes  that  construct  dialogues.  Modified 
Petri  nets  are  used  to  represent  the  organization  and  structure  of 
dialogue  and  process  control. 

Borufka,  Kuhlmann,  and  ten  Hagen  [ BORU82 ]  employ  a  mechanism 
called  "dialogue  cells"  which  provide  a  basic  approach  and  several 
tools  to  aid  in  the  programming  of  dialogues  for  interactive  user 
interfaces.  Separate  roles  include  those  of  an  application  program¬ 
mer  and  a  dialogue  designer.  A  dialogue  tool  providing  input/output 
access  to  graphical  devices  reflects  their  heavy  emphasis  on  graph¬ 
ics.  Programming  language  extensions  for  programming  of  dialogues 
are  part  of  their  approach  to  dialogue  construction,  as  an  extension 
of  the  programming  activity.  Dialogue  "cells"  are  proposed  as  a  gen¬ 
eric  model  for  instances  of  human-computer  interaction,  using  the 
basic  elements  of  prompt,  echo,  user  input  symbol,  and  user  input 
value.  Dialogue  cells  are  combined  to  model  sequences  of  interac- 
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3.4.  INTERFACES  AS  LANGUAGES 

The  kind  of  tools  discussed  above,  for  formatting  graphical  and 
textual  parts  of  dialogue,  clearly  should  be  included  as  part  of  a 
dialogue  tool  facility.  This  section  singles  out  for  discussion  a 
less  obvious  tool  area,  but  one  which  is  perhaps  the  most  important 
of  all.  Because  the  user  of  a  human- computer  application  system  must 
interact  with  that  system  through  dialogue,  it  is  evident  that  this 
dialogue  comprises  the  interaction  language  between  the  system  and 
its  users.  Beyond  this  apparent  relationship,  a  view  of  the  various 
interactions  that  occur  through  interfaces  as  expressions  from  for¬ 
mally  defined  languages  can  be  useful  in  learning  how  to  design  the 
software  that  deals  with  dialogue. 

For  this  purpose,  user-computer  interactions  can  be  categorized 
into  one  of  two  classes:  1)  unilateral  command  string  or  2) 
request/response  sequence.  The  unilateral  command  string  variety  of 
interaction  begins  with  a  prompt,  and,  therefore,  itself  is  part  of  a 
generalized  request/response  sequence.  But  the  prompt  is  usually  a 
standard  prompt  not  specific  to  the  situation.  For  example,  one 
might  see  a  single  "Ready"  message  at  the  command  level  of  an  operat¬ 
ing  system  or  text  editor.  A  command  in  this  case  is  "unilateral"  in 
the  sense  that  it  is  user-initiated  and  the  system  does  not  present 
to  the  user  the  choices  for  command  names,  followed  by  a  series  of 
interactions  to  obtain  the  parameters  and  options.  The  command  is 
accepted,  lexically  analyzed,  parsed,  recognized  as  a  valid  command 
or  as  an  error,  and  acknowledged  as  a  valid  command  (sometimes  impli¬ 
citly  through  the  presentation  of  the  next  prompt)  or  error.  The 
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action  requested  by  the  command,  if  valid,  is  performed.  The  com¬ 
mands  are  phrased  in  a  formally  defined  grammar,  and  there  is  no  dif¬ 
ficulty  in  seeing  this  as  a  situation  involving  an  interaction  lan¬ 
guage  whose  syntactic  form  can  be  defined  by  a  Backus-Naur  Form  ( BNF ) 
grammar  or  by  any  other  commonly  used,  formal  language-defining  tech¬ 
nique.  Each  command  has  a  well-defined  set  of  semantic  actions. 

The  request/response  case  does  not  require  the  user  to  unilater¬ 
ally  synthesize  a  command,  but  allows  the  user's  needs  to  be  conveyed 
by  a  sequence  of  request/response  interactions.  The  syntactic  forms 
for  request/response  interactions  include  menus,  touch  panels,  key¬ 
pads,  and  ordinary  question-and-answer  text.  The  same  kind  of  com¬ 
mand  that  is  found  in  the  unilateral  case  can  be  built  up  by  select¬ 
ing  a  function  and  then  selecting  (or  specifying),  one  at  a  time,  the 
parameters  and  options.  The  user  is  coached  for  each  item  and  does 
not  need  to  Know  a  syntax  for  the  command.  In  a  system  without  sepa¬ 
ration  of  dialogue  and  computation,  the  application  software  must 
handle  these  interactions  by  asking  for  each  input,  accepting  it, 
performing  lexical  analysis  (and  sometimes  parsing),  recognizing  the 
input  as  valid  or  erroneous  (including  validation  of  values  for  type 
and  range),  and  then  performing  the  required  action.  In  a  system 
with  separation,  the  programmer  need  not  be  concerned  with  all  of 
these  functions,  and  the  dialogue  author  can  deal  with  them  through  a 
set  of  automated  tools. 

The  unilateral  command  string  is  often  considered  to  be  most 


suited  for  "expert"  users,  while  request/response  interactions,  are 
typically  reserved  for  verbose  "novice"  users.  At  least  one  system. 


however,  [ROBE79]  uses  menus  within  a  fast  communication  system  as 
its  primary  means  of  interaction  with  all  levels  of  users. 

While  the  syntactic  forms  of  request/response  sequences  are 
quite  different  from  those  of  regular  command  string  languages,  many 
of  the  processing  requirements  (i.e.,  lexical  analysis,  parsing, 
recognition,  and  validation)  are  similar.  The  difference  is  that  the 
request/response  approach  breaks  the  application  system  down  into 
numerous  "micro-languages"  whose  processing  can  be  done  in  a  local¬ 
ized  manner.  That  is,  at  a  given  point  in  a  particular  sequence, 
only  a  very  small  grammar  is  required  to  describe  the  valid  inputs  at 
that  point. 

Researchers  have  realized  for  some  time  that  severe  limitations 
exist  in  the  notations  typically  used  to  specify  a  language.  Repre¬ 
sentational  schemes  are  generally  so  highly-coded  that  they  become 
almost  unreadable  to  the  average  person.  Formal  language  definitions 
meet  with  resistance,  especially  from  more  practically  oriented 
users,  because  they  are  so  cryptic  and  often  difficult  to  understand. 
The  reader  of  a  language  definition  should  be  able  to  quickly  grasp 
the  formalism  and,  from  it,  extract  the  information  needed.  This  can 
be  done  only  through  the  development  of  a  readable  notation  that  will 

describe  the  complete  syntax  of  a  language  (LEDG74).  Attention  to 
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the  design  of  the  language  specification,  so  that  the  general  user 
can  understand  it,  will  help  overcome  some  of  the  resistance  normally 
encountered  in  the  use  of  formal  language  definitions  [MARC76]. 

There  are  several  established  methods  of  language  syntax  repre¬ 
sentation,  the  best  known  example  of  which  is  Backus-Naur  Form  (BNF) 


[ NAUR63 ] .  However,  most  of  these  are  used  primarily  for  representa¬ 
tion  of  static  programming  languages  and  are  inadequate  for  represen¬ 
tation  of  dynamic  interaction  languages  [ JAC082 ] .  BNF  has  some  human 
factors  problems  as  well.  It  is  a  highly-structured,  hierarchical 
metalanguage  that  results  in  a  "fan-out"  problem.  That  is,  non-ter¬ 
minals  in  an  expression  can  be  replaced  by  more  non- terminals  through 
several  successive  iterations  before  a  terminal  symbol  is  finally 
reached.  This  multi-level  tree  structure  is  difficult  to  follow, 
since  by  the  time  the  leaves  (terminals)  are  reached,  the  root  (high¬ 
est  level  expression)  may  long  be  forgotten. 

One  variant  of  BNF,  designed  specifically  to  represent  interac¬ 
tive  languages  rather  than  static  languages,  is  the  multi-party  gram¬ 
mar  [SHNE82b].  The  features  which  differentiate  this  extension  from 
standard  BNF  are  the  labeling  of  nonterminals  with  a  party  (i.e., 
either  human  or  computer)  identifier,  assignment  of  values  to  nonter¬ 
minals  when  appropriate,  and  definition  of  a  nonterminal  which  will 
match  any  input  string  if  no  other  parse  of  that  input  is  successful. 
Other  issues  involving  visual  features  peculiar  to  interactive  dis¬ 
plays  are  also  incorporated.  Because  of  their  interactive  nature, 
reguest/response  sequences  are  good  candidates  for  description  by 
multi-party  grammars  [SHNE82b].  The  idea  of  describing  interfaces  by 
a  formal  language  specification  has  also  been  addressed  by  Foley 
[F0LE81].  A  rigorous  definition  of  input,  output,  and  the  relation¬ 
ship  between  them  leads  to  a  more  structured  design  environment  and 
again  emphasizes  human-computer  interface  development.  Formal  gram¬ 
matical  descriptions,  combined  with  experimental  results,  are  being 
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used  to  compare  alternative  human-computer  interface  designs  for  ease 
of  use  [ REIS81 1 . 

A  fundamental  basis  underlying  these  methods  for  language  repre¬ 
sentation  is  the  notion  of  a  metalanguage,  which  is  a  language  to 
describe  the  syntax  of  other  languages.  All  of  the  approaches  to 
language  specif ication  described  above  contain  examples  of  metalan¬ 
guages.  One  of  the  great  difficulties  in  dealing  with  metalanguages 
through  a  computer  interface  is  in  keeping  the  symbols  of  the  meta¬ 
language  disjoint  from  the  symbols  of  the  language  being  specified. 
Since  most  user  languages  make  use  of  all  the  keys  on  a  typical  ter¬ 
minal  keyboard,  there  are  none  left  to  use  unambiguously  as  metalan¬ 
guage  symbols.  A  simple  example,  but  one  that  recurringly  causes 
problems  with  naive  users,  is  seen  in  the  following  informal  language 
definition  to  a  user: 

Type  "EXIT"  to  leave  the  program. 

It  is  not  clear  (and  cannot  be  made  clear  without  special  meta-meta- 
language  conventions  concerning  the  use  of  quotation  marks  and  upper 
and  lower  case  letters)  what  the  user  should  type.  Should  the  quota¬ 
tion  marks  be  typed?  Must  EXIT  be  typed  in  only  upper  case  letters, 
or  will  lower  case  work,  too?  Other  examples  include  the  choice  of 
symbols  for  delimiters  (which  can  also  be  dependent  on  the  context  of 
that  which  is  being  delimited),  the  representation  of  required  versus 
optional  elements,  notation  for  a  choice  among  alternatives,  special 
representation  of  conditionally  optional  components  (including  the 
conditions  themselves),  constraints  on  alternatives  caused  by  choices 
made  elsewhere  in  the  expression,  and  limitations  on  values  and  char¬ 
acters  to  be  used  in  parts  of  the  command  string. 


Because  of  this  strong  relationship  of  human-computer 
interaction  to  language  construction,  consideration  of  language 
design  and  implementation  must  be  a  part  of  dialogue  management. 
Automated  tools  are  needed  for  both  language  specification  and  defi¬ 
nition,  and  parser  generation  for  language  recognition.  Since  the 
dialogue  author  is  not  expected  to  be  a  language  specialist,  human 
factors  is  an  especially  important  part  of  those  tools. 

3.5.  DIRECT  MANIPULATION 

Direct  manipulation  is  a  concept  relating  to  interfaces  as  lan¬ 
guages.  Direct  manipulation  allows  a  user  to  move  the  cursor  to 
objects  (both  graphical  and  textual),  move  objects,  and  perform  oper¬ 
ations  on  objects  with  immediate  visual  feedback.  Through  direct 
manipulation  [SHNE82a],  naive  users  can  use  computing  facilities 
without  having  to  know  a  complicated  command  language.  The  "syntax" 
has  become  less  computer-oriented  and  more  user-oriented.  Computer 
arcade  games  are  striking  examples;  it  is  impossible  to  imagine  play¬ 
ing  Tempest  by  typing  in  the  kind  of  commands  one  typically  finds  in 
a  line  editor! 

System  design  for  direct  manipulation  requires  the  means  for  an 
exact  visual  representation  of  the  objects  and  their  relationships. 
This  requirement  reflects  a  concept  in  dialogue  management  sometimes 
known  as:  "What  you  see  is  what  you  get".  It  is  antithetical  to 
this  concept,  for  example,  to  build  a  file  of  text  with  imbedded  com¬ 
mands  for  its  formatting,  as  one  does  with  many  present-day  text  for¬ 
matters.  A  facility  for  visual  programming  [ MACD82 ]  ought  to  be 
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offered  in  the  tools  provided  to  system  designers  and  builders, 
especially  to  the  dialogue  author.  It  is  more  direct  for  an  author 
to  build  a  display  for  an  end-user  by  creating  and  manipulating 
boxes,  circles,  and  text  on  a  display  screen  than  to  build  it  by  dia¬ 
logue  programming  with  an  extended  programming  language,  as  in 
I BORU82 ] . 


4.  HOLISTIC  METHODOLOGICAL  APPROACH 


As  the  preceding  section  has  shown,  the  importance  of  a  struc¬ 
tured  approach  to  software  development  is  well-recognized.  However, 
the  addition  of  the  dialogue  author  to  the  overall  system  design  team 
increases  communication  complexity  in  an  already  sizable  group 
(including  application  programmer,  systems  analyst,  application 
expert,  user,  and  human  factors  expert).  One  of  the  most  important 
concepts  in  dialogue  management  relates  to  the  need  for  a  system 
design  methodology  which  emphasizes  a  holistic  approach  to  software 
design,  so  that  both  dialogue  and  computational  components  of  a  sys¬ 
tem  are  given  consideration.  Such  a  methodology  must  also  facilitate 
inter-role  communication  between  the  dialogue  author  and  the  applica¬ 
tion  programmer. 

A  holistic  approach  to  design  methodology  treats  dialogue  design 
as  an  integral  part  of  the  entire  software  system  design.  Without 
this  integration,  one  can  perhaps  achieve  separation  of  dialogue  from 
application  programs,  but  not  true  dialogue  independence.  This  is 
why  tuning  the  dialogue  with  an  add-on  front-end  to  an  existing 


application  is  not  entirely  effective.  "Silk  purse"  user  interfaces 
cannot  be  fabricated  from  "sow's  ears"  logical  control  structures,  no 
matter  how  well  the  dialogue  form  and  content  are  refined. 

The  development  of  a  large  software  system  is  a  complex  task 
even  without  considering  the  necessity  for  a  human-factored  end-user 
interface.  Thus,  the  relatively  new  field  of  software  engineering 
has  devoted  much  of  its  effort  to  reducing  this  development  complex¬ 
ity  with  little  regard  for  the  human  factors  that  so  greatly  affect 
the  performance  of  the  end-user  of  the  system.  Current  software 
development  methodologies  are  aimed  at  facilitating  the  job  of  the 
application  programmer  by  providing  tools  and  guidelines  for  system 
analysis,  design,  implementation,  and  maintenance.  They  rarely  con¬ 
sider  the  guidelines,  methods,  and  tools  needed  to  produce  quality 
human-computer  interfaces.  As  a  result  of  using  these  methodologies, 
the  effectiveness  of  the  human-computer  interface  varies  according  to 
the  human  factors  knowledge  of  the  application  programmer,  and  with 
the  emphasis  that  the  programmer  gives  to  this  interface.  Recent 
advances  in  methodological  development  have  seen  more  emphasis  on  the 
role  of  the  human  factors  expert  in  system  design.  But  just  as  the 
programmer's  knowledge  of  human  factors  is  varying,  the  human  factors 
expert's  knowledge  of  programming  is  varying.  Therefore,  for  these 
two  specialists  to  work  together  effectively,  a  methodology  is 
required  which  embodies  the  needs  and  principles  of  both  the  discip¬ 
line  of  software  engineering  and  of  human  factors  engineering,  while 
providing  appropriate  development  and  communication  tools  for  each. 
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Creating  an  application  system  which  includes  both  dialogue  and 
computational  components  is  different  from  the  development  of  a  trad¬ 
itional  software  system.  Traditional  software  methodology  is  inade¬ 


quate  because  it  fails  to  fulfill  the  following  requirements: 

1.  Integration  of  human  factors  inputs  from  the  beginning  of  sys¬ 
tem  development, 

2.  Separation  of  dialogue  author  and  programmer  roles, 

3.  Minimization  of  computer  knowledge  required  for  system  design, 

4.  Incorporation  of  both  data  flow  and  control  flow  in  a  single 
unified  representation, 

5.  Production  of  requirements  specifications  that  are  easy  to 
verify  in  the  design,  and 

6.  Use  of  an  automated  tool  environment  for  development  of  dia¬ 
logue  and  computational  components. 

An  example  of  a  holistic  methodology  which  meets  these  requirements 
will  be  discussed  in  section  5.2.3  in  the  context  of  a  specific  sys¬ 
tem  for  dialogue  management. 

Foley  [F0LE81]  reports  on  a  four-phase  methodology  for  designing 
a  user  interface.  The  first  step,  conceptual  design,  specifies  the 
user's  view  of  the  application  system.  The  semantic  design  phase 
determines  system  functionality,  while  syntactic  design  deals  with 
sequencing  of  input  and  output.  Finally,  the  lexical  phase  maps  syn¬ 
tax  to  specific  hardware  devices.  This  kind  of  methodological 
approach  gives  emphasis  to  development  of  the  user  interface,  while 
providing  the  structure  to  handle  the  complexity  of  application  sys¬ 
tem  design. 


29 


5.  A  DIALOGUE  MANAGEMENT  SYSTEM 


The  concepts  discussed  in  this  paper  represent  a  new  approach  to 
the  management  of  dialogues  in  the  development  of  human-computer 
interfaces.  However,  recognition  of  these  concepts  is  not  sufficient 
to  produce  improved  human- computer  interfaces.  Demonstration  of  the 
effectiveness  of  these  concepts  requires  application  system  develop¬ 
ment  facilities  and  tools  which  incorporate  them  from  the  first 
phases  of  design  all  the  way  through  to  implementation.  As  one  pos¬ 
sible  system  to  illustrate  the  concepts,  a  Dialogue  Management  System 
(DMS)  [HART82 ]  is  described  below. 

5.1.  OVERVIEW  OF  DMS 

DMS  is  a  comprehensive  system  for  designing,  analyzing,  imple¬ 
menting,  and  monitoring  human- factored  interactive  application  sys¬ 
tems.  The  high-level  DMS  organizational  framework  which  supports  the 
concepts  of  dialogue  management  is  shown  in  Figure  3.  DMS  provides 
an  environment  which  facilitates  the  design  and  implementation  of 
both  dialogue  and  computational  components  in  parallel.  The  compo¬ 
nents  of  the  environment  which  effect  this  parallel  development  are 
shown . 
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Figure  3.  High-Level  Organization  of  DMS 

5.2.  DIALOGUE  MANAGEMENT  CONCEPTS  IN  DMS 

The  concepts  of  dialogue  management  which  have  been  presented  in 
this  paper  are  embodied  in  DMS.  The  implementation  of  dialogue  inde¬ 
pendence,  the  role  of  the  dialogue  author,  and  a  holistic  methodolo¬ 
gical  approach  form  the  underlying  basis  of  DMS. 

5.2.1.  Dialogue  Independence 


Dialogue  independence  is  manifest  logically  in  DMS  through  the 
use  of  separate  modules  for  dialogue  and  computation  in  the  applica- 
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tion  systems  produced  using  DMS.  Separate  interfaces  are  provided 
for  the  creation  of  dialogue  and  for  computational  software.  The 
integrated  dialogue  components  and  computational  components  form  the 
completed  application  system.  Physically,  dialogue  independence  is 
achieved  in  DMS  by  the  use  of  a  multiprocess  execution  environment. 
In  this  environment,  the  dialogue  component  and  the  computational 
component  are  executed  in  separate,  but  concurrent,  operating  system 
processes.  Finally,  device  independence  is  accomplished  by  general¬ 
ized  device  drivers  for  each  hardware  device  which  is  used  in  DMS 
(e.g.,  a  graphics  terminal  and  a  black-and-white  CRT),  to  localize 
the  characteristics  of,  and  differentiate  among,  display  devices. 

5.2.2.  Dialogue  Author 

The  role  of  the  dialogue  author  is  separate  from  that  of  the 
application  programmer  in  DMS.  As  shown  in  the  DMS  structural  organ¬ 
ization,  different  interfaces  and  tools  are  provided  for  each  role. 
The  application  programmer,  through  the  application  programmer  inter¬ 
face,  uses  the  comp,. tational  development  facility  to  create  the  com¬ 
putational  component  of  an  application  system.  No  external  dialogue, 
or  interaction  with  the  user,  is  produced  by  this  portion  of  DMS. 
Only  the  internal  dialogue,  or  the  interaction  between  dialogue  and 
computational  components,  is  a  part  of  the  software  developed  using 
this  tool.  At  the  same  time,  the  dialogue  author  uses  the  author's 
interface  to  create  the  dialogue  portion  of  an  application  system. 
This  Author's  Interactive  Dialogue  Environment  (AIDE)  is  the  portion 
of  DMS  with  which  a  dialogue  author  designs,  implements,  simulates, 
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tests,  and  modifies  dialogues.  It  provides  an  automated  set  of  tools 
for  a  dialogue  author  to  use  in  creating  human-factored  human-compu¬ 
ter  dialogues.  This  set  of  tools  consists  of  such  aids  as  a  dialogue 
editor,  a  graphical  formatter,  a  menu  formatter,  a  voice  I/O  manager, 
a  language  implementer,  a  dialogue  simulator,  and  a  dialogue  data¬ 
base.  The  output  produced  by  AIDE  is  external  dialogue,  or  the 
interface  through  which  an  end-user  communicates  with  the  completed 
application  system.  A  complete  presentation  of  AIDE,  its  tools,  and 
its  use  by  a  dialogue  author  can  be  found  in  [J0HN82a]. 

A  language  implementer,  one  of  the  tools  of  AIDE,  assists  the 
dialogue  author  in  the  design,  specification,  and  recognition  of 
interaction  languages  [JOHN82b].  The  language  implementer  consists 
of  two  main  components:  1)  a  tool  to  aid  in  creating  an  interaction 
language  and  its  specification  for  a  specific  application  system,  and 
2)  a  tool  to  generate  a  parser  to  recognize  this  interaction  lan¬ 
guage,  once  it  is  incorporated  into  the  application  system.  Syntac¬ 
tic  forms  include  menus,  touch  panels,  keypads,  and  command  strings. 
Additionally,  the  language  implementer  alleviates  the  difficult  prob¬ 
lem  of  determining  whether  the  dialogue  author  or  the  application 
programmer  should  do  input  parsing.  Input  from  the  user  to  the  sys¬ 
tem  is  really  part  of  the  external  dialogue,  and  as  such,  should  be 
handled  by  the  dialogue  author.  But  an  author  generally  does  not 
have  the  skills  necessary  to  create  parsers.  The  language  implemen¬ 
ter  is  an  automated  tool  in  AIDE  that  the  dialogue  author  can  easily 
use  to  do  input  recognition  when  needed,  through  the  automatic  gener¬ 
ation  of  lexical  analyzers  and  parsers. 
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Direct  manipulation  and  "what  you  see  is  what  you  get"  are 
achieved  by  having  a  very  general  display  representation.  Each 
screen  in  represented  in  the  AIDE  environment  within  a  high  perfor¬ 
mance  (primary  memory)  relational  Screen  Database  (SDB)  containing 
relations  to  hold  attribute  values  for  the  screen  and  its  objects  and 
groups  of  objects.  The  SDB  is  manipulated  by  a  set  of  generalized 
editing  functions.  The  direct  manipulation  functions  (via  keypad 
selection  and  cursor  movement  through  the  author's  interface)  use 
these  editing  functions  to  manipulate  the  objects  on  the  screen  and 
therefore  in  the  database. 

The  display  on  the  screen  at  the  author's  workstation  is  cons¬ 
tantly  kept  current  with  the  SDB  representations  by  a  Display  Inter¬ 
preter.  Storing  dialogue  in  an  interpretable  representation  produced 
by  AIDE  tools  is  a  key  to  dialogue  independence,  since  local  changes 
to  dialogue  do  not  affect  the  computational  component  of  an  applica¬ 
tion.  Screen  definitions  are  retrieved  (stored)  into  (from)  the  SDB 
from  (into)  the  Dialogue  Database  (DDB),  which  holds  the  dialogue  for 
a  complete  application  system.  For  performance  reasons,  special 
methods  are  applied  to  "compile"  the  DDB  contents  when  the  applica¬ 
tion  is  ready  for  execution. 

5.2.3.  Holistic  Methodology 

Because  traditional  software  methodologies  have  been  found  to  be 
inadequate  for  dialogue  management,  a  new  methodology,  called  the 
Supervisor-Based  System  Development  Methodology  (SBSDM)  has  been 
developed  [  YUNT82  j  for  use  in  DMS .  Applicable  to  the  modelling  of 
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any  procedural  system,  the  SBSDM  integrates  many  of  the  features  of 
conventional  methodologies  (the  equivalent  of  data  flow  diagrams, 
structure  charts,  PDLs,  structured  design,  etc.)  into  a  single 
approach,  which  integrates  human  factors  considerations  from  the  ear¬ 
liest  stages  of  design.  Based  on  a  separation  of  dialogue  author  and 
application  programmer  roles,  and  the  fact  that  the  author  need  not 
be  a  computer  specialist,  the  SBSDM  combines  both  data  flow  and  con¬ 
trol  flow  into  requirements  and  design  representation  at  all  levels 
of  system  development. 

The  basic  element  of  the  SBSDM  is  a  "supervisory  structure". 
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Supervisory  Structure  and  Supervisory  Cells 


which  is  a  hierarchy  of  "supervisory  cells"  (see  Figure  4).  Each 
cell  represents  the  subfunctions  of  a  single  supervisory  function.  A 
Supervised  Flow  Diagram  (SFD)  represents  the  sequence  of  subfunctions 


and  indicates  both  control  flow  and  data  flow  among  the  subfunctions. 
The  supervisory  function  of  an  SFD  administers  both  data  flow  and 
control  flow.  Each  subfunction  can  then  be  a  supervisory  function  of 
supervisory  cells  at  the  next  level  in  the  hierarchy.  Worker  func¬ 
tions,  which  perform  single  dialogue  or  computational  operations,  are 
found  in  the  terminal  nodes  of  the  supervisory  structure.  All  the 
supervisory  functions,  taken  together,  make  up  the  control  structure 
of  the  entire  application  system.  Details  of  the  SBSDM,  and  examples 
of  its  use,  are  to  be  found  in  [ YUNT82 ] . 


The  supervisory  structure  is  used  to  represent  the  application 
system  in  all  phases  of  development  in  the  software  lifecycle.  The 
requirements  analysis  and  specification  phase  begins  with  a  "wish 
list"  from  the  application  experts  and  users.  This  list  is  converted 
into  a  high-level  supervisory  structure  by  the  human  factors  engi¬ 
neers  and  software  engineers/systems  analysts.  When  it  has  been 

expanded  until  its  terminal  nodes  are  pure  computation  or  pure  dia- 

» 

logue,  this  structure  is  called  the  "behavioral  structure",  which  is 
a  complete,  precise  statement  of  the  system  requirements.  Only  the 
development  of  the  computational  and  dialogue  supervisory  functions 
in  worker  modules  is  required  to  complete  the  physical  design. 
Implementation,  then,  amounts  to  a  direct  mapping  of  this  representa¬ 
tion  to  source  code.  This  graphical  SFD  language  of  the  behavioral 
structure  is  a  very  high-level  programming  language,  and,  since  the 
methodology  is  supported  by  an  automated  tool  environment,  the  source 
code  for  the  entire  control  structure  can  be  generated  using  a  SFD 
language  compiler.  Thus,  the  behavioral  structure  provides  a  graphi- 
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cal  representation  that  is  itself  executable.  All  application  system 
sequences  can  be  tested  before  any  other  code  is  written.  Because 
the  behavioral  structure  is  executable,  there  is  no  need  for  a  trans¬ 
lation  step  from  the  requirements  to  the  design  and  implementation, 
and  no  need  to  verify  that  the  design  and  implementation  meet  the 
requirements.  The  only  remaining  tasks  are  the  writing  of  the  compu¬ 
tational  modules  by  the  application  programmer  and  the  production  of 
the  terminal  dialogue  modules  by  the  dialogue  author. 

This  methodology  recognizes  and  addresses  the  fact  that  in  order 
to  deal  effectively  with  dialogue,  system  developers  must  work  with 
the  entire  system.  SBSDM  incorporates  the.  dialogue  management  con¬ 
cept  of  dialogue  independence  into  system  design,  and  provides  for 
effective  interaction  between  the  new  role  of  the  dialogue  author  and 
the  traditional  role  of  the  application  programmer. 


_  6 .  SUMMARY 

? 

1  « 

The  need  for  effective  human- computer  interfaces  is  well-recog- 
nized.  However,  most  research  in  software  engineering  has  emphasized 
mainly  the  computational  component  of  a  system,  while  the  dialogue  is 
developed  as  a  secondary  activity.  In  order  to  address  this  issue, 

v  several  important  concepts  of  dialogue  management  have  been  identi- 

is 

fied.  Dialogue  independence,  which  results  in  the  separation  of  dia- 
logue  and  computational  components  within  a  software  system,  allows 
easy  modification  of  dialogues  so  that  a  human-computer  interface  can 
^  be  quickly  modified  to  meet  the  needs  of  its  users.  The  role  of  a 


dialogue  author,  whose  main  purpose  is  to  create  dialogues  that 
incorporate  good  human-computer  interface  guidelines,  is  another  key 
concept.  By  automating  as  much  of  the  dialogue  development  and 
implementation  process  as  possible,  the  dialogue  author  is  freed  from 
much  of  the  tedium  of  "coding"  dialogues  and  can  concentrate  on 
incorporating  human  factors  into  the  dialogues  to  create  an  effective 
human-computer  interface.  An  Author's  Interactive  Dialogue  Environ¬ 
ment  (AIDE)  is  being  developed  as  one  such  system  for  use  by  the  dia¬ 
logue  author.  This  environment  consists  of  numerous  automated  tools 
for  assisting  in  both  dialogue  design  and  implementation.  This 
places  the  emphasis  of  human-computer  interface  development  on  what  a 
dialogue  will  contain,  not  on  how  it  will  be  implemented.  Finally,  a 
system  which  incorporates  dialogue  independence  and  which  is  created 
by  a  dialogue  author  and  an  application  programmer  working  in  para¬ 
llel  must  be  developed  by  employing  a  methodological  approach  which 
considers  the  entire  software  system.  A  holistic  methodology  of  this 
type  provides  for  coordination  of  the  roles  as  well  as  integration  of 
the  dialogue  and  computational  components  which  are  independently 
produced. 

Many  aspects  of  human-factoring  an  application  system  user 
interface  seem  intuitively  obvious,  even  to  the  casual  observer.  But 
these  aspects  are  all  too  frequently  ignored  in  the  rush  to  produce 
an  operational  system  as  soon  as  possible.  Anything  that  takes  time 
away  from  programming  is  considered  by  many  people  to  be  non-produc¬ 
tive.  But  application  systems  which  are  developed  without  proper 
attention  to  the  human-computer  interface  are  frequently  ineffective 
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for  the  end-user.  With  ever-increasing  numbers  of  interactive  compu¬ 
ter  users  having  wide  ranges  in  experience,  problems,  and  expecta¬ 
tions,  the  need  for  effective  human- computer  interfaces  becomes  a 
primary  input  to  system  design.  Ad  hoc  design  methods  and  tradi¬ 
tional  manual  development  tools  will  rarely  produce  satisfactory  sys¬ 
tems.  Providing  a  standard  methodology  and  automated  tools  for  the 
creation  of  useful,  effective  human-computer  interfaces  is  "a  chal¬ 
lenge  to  scientific  competence,  engineering  ingenuity,  and  artistic 
elegance"  [ SHNE80 ] . 

The  concepts  presented  in  this  paper  are  being  incorporated  into 
an  automated  Dialogue  Management  System  (DMS)  to  be  used  for  the 
development  of  human-computer  systems.  However,  such  a  DMS  is  not  a 
prerequisite  for  improved  dialogue  design.  More  effective  human-com¬ 
puter  interfaces  can  presently  be  produced  by  using  the  concepts  of 
dialogue  independence,  a  dialogue  author,  and  a  comprehensive  holis¬ 
tic  methodology  in  the  development  of  human-computer  systems. 
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